BBS in a Box 15/BBS in a box XV-1.iso/Files/Internet/TCP-PPP-SLIP/MacTCP Info 1.3.sit/mactcp-info-13

Text File | 1995-02-22 | 72.5 KB | 1,625 lines | [TEXT/R*ch]

(Note to the Archivers: this file should be stored as
 info-mac/comm/info/mactcp-info-13.txt; it obsoletes
 info-mac/comm/info/mactcp-info-12.txt)


MacTCP and related Macintosh software
=====================================
revision 1.3, February 14, 1995

----------------------------------------------------------------
Copyright Eric Behr, Northern Illinois University, Mathematics
Department ([e-mail])

This document can be freely redistributed in whole or in part,
provided that this copyright notice is included intact, and that
no material profit is generated from such a transaction.
----------------------------------------------------------------

With sincere thanks to:
  Jim Browne -- for his HTML version of the previous revision
  David N. Blank-Edelman, Steve Dorner, Patrick Hoepfner,
     Peter N. Lewis, David S. Saunders -- for reviewing the
     previous revisions
  Adam Engst and Patrick Hoepfner (again!) for extensive comments
     about this version
  Mikael Hansen -- for his nagging

as well as to several contributors to Usenet newsgroups, and to all
those who sent me corrections and suggestions (but I'm the sole
author of all mistakes, omissions and inanities).

The newest release of these notes can be obtained by anonymous ftp to
ftp.math.niu.edu (the text file /pub/mac/doc/mactcp.txt), or by gopher
to gopher.math.niu.edu ("Help Files/Help For Macintosh Users"), or
as http://www.math.niu.edu/~behr/docs/mactcp.html. The HTML version
is usually updated first and may be more accurate.

Please send all comments and suggestions to [e-mail].

If you want to make me and my family happy, please send a postcard to
  Eric Behr
  NIU, Math, WH 320
  DeKalb, IL 60115
Thank you!
----------------------------------------------------------------


CONTENTS

            PREFACE
         I. Generalities
        II. MacTCP
       III. Installation
        IV. Configuration
         V. Applications
        VI. Sources
Appendix A. FTP primer
Appendix B. Elements of Macintosh networking
Appendix C. Dial-in access
Appendix D. MacTCP error codes

----------------------------------------------------------------


PREFACE

In the past few years the Internet, once an obscure tool used
primarily by academicians, has become a household word. This surge in
popularity created great demand for information about software used
to connect to the "Net", and to navigate its vast expanse.

Macintosh users are blessed with a cornucopia of excellent and
innovative software packages for use with the Internet. Nearly all of
them use the MacTCP driver from Apple.

I've spent many hours installing MacTCP on various Macs. I also
devoted a large part of my free time to digging up various useful
applications for use on the Internet. Hopefully some of my
experiences will be helpful to you.

Please note that I'm not a networking expert. Moreover, in recent
months I have been involved with Macs much less than I used to, so
some of my advice is second-hand.

Those readers who are new to the field of Macintosh networking might
get something out of Appendix B -- please look at it before you
continue.


I. Generalities

1. Let's begin with a short sermon

I started using the Internet several years ago, and it has become an
important part of my life - for better or worse. I know that many
people share my feelings about it. For the sake of all of us, please
be considerate! There are lots of things you can mess up if you don't
know what you are doing. Connecting your computer to the network
which spans continents and is used by millions of people in their
work is (or at least should be) a serious act.

Please follow this simple advice:

o  when in doubt, don't do anything without consulting your
   local knowledgeable system administrator -- chances are that
   if you don't, you will break more than you'll fix;

o  read newsgroups such as comp.sys.mac.comm, comp.sys.mac.system,
   comp.sys.protocols.tcp-ip, comp.protocols.appletalk, especially
   the Frequently Asked Questions collections which are posted in
   most newsgroups from time to time;

o  read the flaming manuals!

o  if you are doing something especially tricky, find out how to
   access Internet documents (esp. RFC's) and read the relevant
   ones.


2. Where does the Mac fit in?

The Mac has always been a wonderful network machine. But for most
people "Macintosh networking" means Apple's proprietary system called
AppleTalk. The Internet uses a different networking "language". A
major part of it is the protocol known by its acronym TCP/IP. To
access the wonders of the Internet, a computer must understand
TCP/IP.

Essentially all network software packages available for the Mac use
the "MacTCP driver" from Apple. Despite its flaws, it provides a
uniform interface to the low-level networking mechanisms, which in
the long run makes life much easier for software developers and end
users.


3. Various connection methods

   The necessary software is only one part of a network connection.
The other, obviously, is suitable hardware. A Macintosh can be
connected to the outside world in many ways:

o  with a LocalTalk or PhoneNet connector
o  with an Ethernet adapter
o  with a TokenRing adapter
o  with a modem and suitable software

The first three methods are more reliable and provide higher speeds
than the last one. However, modem connections are becoming more and
more popular.

Macs on Ethernet can usually connect to the outside TCP/IP world
without a problem; for a long time TCP/IP has been the protocol of
choice on Ethernet networks. From the hardware point of view, all
that is required here is an internal Ethernet card, an external SCSI
Ethernet adapter, or -- for Macs with built-in ethernet -- a
transceiver with a connector suitable for your flavor of Ethernet:
coax, 10Base-T, or thick.

If you aren't sure which gadget to order, look at the network cables
used throughout your site. Black TV-style cables mean that you need a
coax, or 10Base-2 adapter. Thinner cables with modular plugs (like
telephone ones, only a bit larger) indicate an "unshielded twisted
pair", i.e. 10Base-T installation. Finally, if all you see is a
(usually yellow) cable the thickness of a finger, you may need a
special AUI drop cable which can be plugged into your adapter, and a
thick Ethernet "vampire tap" which needs to be attached to the cable
in a specific spot. In this last case, ask around -- don't do it
yourself. Functionally all three types are identical, and they have
nothing to do with the way MacTCP works.

Macs on LocalTalk can communicate with the outside TCP/IP world only
if the LocalTalk is connected to a larger network using an IP gateway
such as FastPath (Shiva), Gatorbox (Cayman Systems), Multiport
Gateway (Webster Computer Corp.), EtherRoute/TCP (Compatible
Systems), or one of other equivalent devices; or if such a gateway is
present elsewhere on your internet, and is visible to your Mac. For
small networks simpler and cheaper devices or software such as
microBridge/TCP or SuperBridge/TCP from Sonic Systems can be used,
even though they are not full-fledged LocalTalk-to-Ethernet routers.

There are reports of exotic solutions consisting of a PC running
public domain software (PCRoute), with an old Sitka TOPS card,
successfully acting as an IP gateway for a LocalTalk network, but we
have not tried them.

The Apple Internet Router, which is a software package running on a
Mac connected to a LocalTalk and Ethernet networks, can provide
TCP/IP routing between them with the optional IP Gateway module from
Apple.

Macs connected directly to Token Ring can speak TCP/IP provided that
the MacTCP Token Ring Extension from Apple is installed along with
the main MacTCP driver.

At this time software routing of TCP/IP between LocalTalk and Token
Ring is not commercially available (any entrepreneurs out there?) The
PCRoute solution mentioned above may be worth exploring here.

Please note that AppleTalk and TCP/IP are two completely different
animals, even though a single Mac can use both at the same time;
configuring AppleTalk functions, such as printing over the network or
AppleShare, will not be discussed here.


II. MacTCP

1. What is it?

   For the user, it is a hybrid of a Control Panel and a System
Extension; it is configured just as the Monitors or Sound panels are.
For applications, it is a set of procedures which allows them to
communicate with other hosts on the network using the TCP/IP
protocol. It is designed to be transparent in the sense that once it
is properly configured, any correctly written application can make
use of it without user intervention.

A companion product, AdminTCP, is another Control Panel which lets
you lock certain parameters of MacTCP in place after they have been
set. Its function is to help administrators prevent users from
fooling around with previously entered settings. An average person
will not need AdminTCP (you can get it only by purchasing the full
MacTCP kit). It is also possible that your old AdminTCP (version 1.x)
will work with MacTCP 2.0.x, but that has not been extensively tested
and may have dire consequences.


2. How to get it?

MacTCP (version 2.0.6 as of this writing) is marketed by APDA (800
282 2732). Some time ago Apple renamed the entire package "TCP
Connection for the Macintosh", which can makes it easy for dealers to
confuse it with a commercial product from Intercon Systems,
TCP/Connect. We will continue using the generic name "MacTCP".

There are several ways of obtaining MacTCP:

o  check if your institution has a site license (for example, many
universities do)

o  buy it from APDA (about $60 list)

o  buy it from a mail order Macintosh outlet (at the time of this
writing MacWarehouse has it as catalog # NET0389, $49 + shipping)

o  buy a book on the Internet which includes a copy of MacTCP; e.g.
Adam Engst's "Internet Starter Kit for Macintosh, Second Edition"
(ISBN 1-56830-111-1) sells for about $25 or less in decent bookstores

o  buy the newest System Software from Apple; the currently shipping
System 7.5 includes MacTCP

The last two methods are probably most cost-effective; the only
drwaback is that you don't get the less-than-helpful manual, and a
few extra files (which most users won't need anyway).

If you want to inquire about terms of a site license, send e-mail to
[e-mail].

You might still find a copy of MacTCP floating around the Net,
because a few public domain packages used to include the driver.
Beware: those copies are usually old (e.g. MacTCP 1.1.1), and
according to the terms of the license Apple grants developers, such
copies are supposed to be used *only* with the application that
included them. They are not likely to work well with newer system
software and CPUs, so even if you find one you may be in for a lot of
hassle.

Future versions of the system software will include a newer network
driver, currently known as OpenTransport, which replace MacTCP in
function, if not form.


3. Do I have the newest version?

Even though in some cases you might be able to get away with older
revisions of the software, it is a good idea to get the newest one.
Currently shipping System Software 7.5 includes a copy of MacTCP
2.0.4, buried among the PowerTalk support files. Even if you don't
install 7.5 (or PowerTalk), you can use this driver with earlier
releases of the System. The most widely distributed versions seem to
be 2.0.2 and 2.0.4, which were included with some of the very popular
books.

Versions 2.0.2 and 2.0.4 should be patched to 2.0.6 with updaters
distributed on on-line services by Apple (see Part VI for more
information). The updaters only work on original copies of MacTCP. If
you do not have the "virgin" copy, it is possible to modify the
installed one so the updaters will work, but anything involving
ResEdit could be tricky -- do it at your own risk: disable the system
heap bit of the .ipp DRVR resource in the copy you are patching.


III. Installation

   9 times out of 10 MacTCP can be installed simply by copying the
relevant pieces into the System Folder and then configuring them.
Still, non-standard extensions, or corrupted system software might
make this task much more difficult.

My general advice is: start with virginal (or at least freshly
updated) system files. Problems may result from improperly installed
old version of AppleTalk or other resources. For example, I could
never painlessly install new Ethernet drivers on any Mac which
previously had some suspect proprietary network drivers installed on
it. What's worse, some network applications seem to corrupt the
System, and/or other important files, when they crash.

We shall leave those doomsday scenarios for later. In most cases the
following procedure will work. Here we go:

o  When MacTCP is being configured, it creates two files: MacTCP DNR
and MacTCP Prep (under System 7 the latter should end up in the
Preferences folder). If you see old copies of those files in your
System Folder, remove them now!

o  Since some virus protection utilities might think that the new
files that MacTCP is installing in the System folder are viruses, it
is a good idea to shut off all virus protection before you go any
further.

o  If the Mac will be used on Ethernet or Token Ring, make sure you
have installed the necessary physical-level network drivers. For Macs
with built-in Ethernet, the drivers are most likely already there. If
you are using a separately purchased network adapter, follow the
manufacturer's instructions.

Apple's Ethernet drivers can be used with Apple adapters and with
cards from certain manufacturers who maintain high degree of
compatibility with Apple (e.g. Asante). Use the newest Apple Network
Installer Disk, which you should be able to get from the local
dealer, or from ftp.info.apple.com. This is particularly important
with newer Macs.

o  Configure the network drivers, if necessary. Most Ethernet drivers
have no user-changeable settings at all. The Token Ring driver
(configured via its Control Panel) should be set for the correct
speed (4 or 16 Mbps). It also lets you set the hardware address of
the adapter; if your site uses locally administered addresses, you
need to get one from a local administrator, and set the driver
accordingly.

o  If the Mac is to be used with a dial-in connection, install and
configure the relevant extensions and control panels (InterSLIP,
MacSLIP, MacPPP, or similar). Follow the instructions included with
the package. See also Appendix C.

o  Put a fresh copy of MacTCP (and AdminTCP, if you have it -- but it
isn't essential) in the System folder. Make sure that you are using
the newest version, and not one obtained from shady sources. Under
System 7+, the control panel will go into the proper subfolder
automatically if you drop it on top of the System Folder icon.


IV. Configuration

1. Variables

The following questions are crucial to the proper configuration of
MacTCP. Try to find the answers to all of them before you begin.

o  What physical connection method ("link layer") are you using?
Ethernet? dial-up? LocalTalk?

o  Has your Mac been assigned a fixed Internet address, or is it
supposed to be getting its identity from the network? If the former,
what is that address?

o  To connect to hosts outside your LAN, MacTCP needs to know the
address of the "default gateway", a device which links your network
with the outside world. Will the Mac be able to discover it on its
own (this is most often the case)? If not, what is its address?

o  In order to understand symbolic Internet addresses such as
rs.internic.net, rather than only numeric ones like 198.41.0.5,
MacTCP needs to know about "nameservers", i.e. computers which
translate between the two formats. What is the Internet domain in
which the Mac is? What is the address of the master nameserver for
that domain? What is the address of a nearby major nameserver for the
"root domain"?

o  Does your LAN use subnetting? If so, what is the "subnet mask"?

Don't worry if the above sounds like black magic. Most of these
questions can be answered by talking to your network administrator.
Or you may have received this information from the Internet service
provider when you bought dial-up access service. In some cases you
won't need *all* the answers right away.


2. Let's do it!

You should now be ready to configure MacTCP. Open the MacTCP control
panel. You should see a window with one or more icons in the top
part, and a button "More..." in the bottom.

o  Click on the appropriate physical layer setting ("Ethernet
Built-in", "LocalTalk", "Token Ring", "InterSLIP", "PPP", etc.) in
the MacTCP panel (if it gives you that choice). If you are using a
dial-up connection such as SLIP, you should have installed and
configured the serial line drivers before. See Appendix C.

Let me reiterate that the physical link setting has little to do with
the network resource (selected in the "Network" CDEV) which you will
be using for AppleTalk functions, such as printing or AppleShare:
we're dealing with strictly TCP/IP stuff.

Newer system software may refuse to load the low-level networking
support at boot time if AppleTalk is disabled, preventing the Mac
from talking to the network adapter. It's safer to keep AppleTalk
turned on, especially when using built-in Ethernet in the newer Macs.
This is also always the case if you are using TCP/IP through the
LocalTalk port: you must have activated AppleTalk in the Chooser --
otherwise that port is simply dead, and MacTCP doesn't know how to
communicate with the outside world at all.

Here are a few rules-of-thumb for choosing the physical layer:

-  if you use LocalTalk, click the "LocalTalk" icon
-  if you are on Ethernet, click "Ethernet" (or "Ethernet Built-in"
on older Macs); do *not* click the "EtherTalk" icon, unless you were
specifically told that you need to use a remote IP gateway
-  if you are on Token Ring, click "Token Ring" (you must have
installed the MacTCP Token Ring extension)
-  if you are using dial-up connection such as SLIP or PPP, click the
icon of the serial connection driver

Now click the "More..." button. You will see the second level panel
of MacTCP (we'll call it the "inner" panel for brevity).

o  Click the appropriate radio button in the "Obtain address"
section. If the administrator assigned a fixed address to your Mac,
click "Manually". In almost all other cases you will use the "Server"
setting. This means that the Mac's network identity will be obtained
from a device such as the IP gateway, a "bootp server", the dial-up
SLIP server, etc. If you use "Server" or "Dynamic" addressing, you
should skip the steps involving the IP address, network class, and
subnet mask -- that information will be determined by MacTCP "on the
fly". Use "Dynamic" addressing only after you've double-checked that
this is indeed what you need. If your network administrator isn't
very familiar with MacTCP, he may mumble "dynamic" over his shoulder
even when the setting should really be "Server", and this
misunderstanding may cause your boss to curse you because her Mac
will suddenly stop working.

o  If you use "Manual" addressing, you should now click "OK" to go
back to the "outer panel" of MacTCP, and type in the address assigned
to the Mac in the "IP address" edit field. Then click "More..." to
get back to the inner panel.

Please remember that choosing an address at random will at best make
your connections unreliable; it can also provoke unrestrained wrath
of some powerful people in your organization. Courts have been known
to drop bodily harm charges under much weaker extenuating
circumstances. Moreover, some network numbers are illegal on the
Internet. If you pick one of those, you'll be asking for a lot of
trouble - in particular, you'll be getting all e-mail addressed to
the University of Mars for the rest of your life.

In what follows I will use some examples which are real addresses of
real computers on my network; please don't just copy them -- make
sure to change them to ones that are appropriate for your setup!

o  The IP number you were assigned determines the network class.
MacTCP is smart enough to figure it out by itself. Addresses
beginning with 1-127 are class A, 128-191 indicates class B, and
192-254 are class C. After setting an address manually, check that
the correct network class showed up.

o  You should now set the correct subnet mask. If your network does
not use subnetting, make sure that the "Subnet Mask" slider is in a
position where it can't move further to the left (this is the default
setting that MacTCP uses). If you do use subnetting, slide it to the
right so the correct mask such as 255.255.255.0 will show up above.
Do not experiment here! You must use a valid address and subnet mask,
or somebody will soon come looking for you and your scalp.

o  For now leave the "Gateway Address" set to 0.0.0.0; if all goes
well, MacTCP will locate the default gateway by means of a magic wand
called Routing Information Protocol (RIP). If you use "Manual"
addressing and you know that your network does not implement RIP, or
you were told by the manager to use a specific default gateway, you
should enter its address now.

o  The last step is to enter the nameserver information. In the first
row of edit fields under "Nameserver Information" enter the domain of
your Mac (e.g. math.niu.edu), the IP address of the nameserver for
that domain, and click the "Default" button. Now go to the next row,
type a single period in the "Domain" field, then enter the same IP
address as in the first row. Do not click "Default" here.

If you were given additional nameserver addresses, or if you wish to
use a backup nameserver for your domain, enter that information in
the rows below. The net result should be something like this:

 -------------------------------------
| math.niu.edu   | 131.156.3.3    | x |  ("default" button on)
 -------------------------------------
| .              | 131.156.3.3    | o |  ("default" button off)
 -------------------------------------
| .              | 131.156.1.11   | o |  ("default" button off)
 -------------------------------------

Close the MacTCP panel.

o  Even though MacTCP doesn't always tell you to do so, REBOOT now!
Check that MacTCP DNR (and usually MacTCP Prep) files show up in the
System folder.

o  Test MacTCP by running an application such as TurboGopher or
Fetch. If the software doesn't complain, you should be in business.
Try connecting to a reliable host by opening gopher connection to
gopher.micro.umn.edu, or an ftp connection to ftp.rtfm.mit.edu.
Errors such as "connection refused" are OK; this means that the site
is busy. Mac system errors are bad; consult the list in Appendix D.


3. What can go wrong?

If things aren't working right away, you should concentrate on the
following possibilities:

o  bad network or modem connection
o  corrupted copy of MacTCP
o  bad nameserver information
o  bad default gateway setting
o  conflict between system extensions

If you are on a network, the best way to check the connection is to
make sure the Mac can see AppleTalk devices such as printers and
AppleShare file servers. Go to the Chooser and enable AppleTalk (you
may have to reboot after that). Then open the "Network" Control Panel
and select the same physical connection as the one MacTCP is using
(LocalTalk, Ethernet, etc.) Finally, go to the Chooser again and
check whether your local printers and file servers show up. If they
do, you will at least know that the wires are OK.

In case of a dial-up connection, you should obviously look at the
modem lights (the "off hook", "receive data" and "transmit data"
indicators). Most serial drivers such as MacPPP also have an icon or
some other indicator showing whether the driver thinks the connection
is active, but this isn't always reliable. You may have to resort to
diagnosing the modem connection with a serial line "sniffer".

Your network or serial drivers may be corrupted, or misconfigured; it
may be necessary to reinstall them from scratch. You may also be
using an incorrect modem init string; Adam Engst's guide on
troubleshooting such problems can be obtain by mailing a request to
[e-mail].

You can use the MacTCP version of NCSA Telnet to open a connection to
a major site such as rs.internic.net.If Telnet attempts to open a
connection, but nothing happens, you should look at the "Connections"
menu. If it says "XXX is being looked up", chances are that MacTCP
isn't getting responses from the nameservers you gave it. You should
try connecting to a numeric Internet address, e.g. 198.41.0.5.

If Telnet says "XXX is being opened", your Mac may not have the
correct "default gateway" information. Open the MacTCP inner panel
and check whether the 0.0.0.0 gateway setting has changed to
something else. If it didn't, you will have to get the gateway
address from the administrator and enter it manually. If you know the
address of a host on your local network, you can try opening a
connection to it; this should succeed even if the default gateway
isn't set properly.

If your application gives a MacTCP "out of memory" error, you may be
running into a problem caused by the interaction between older
versions of MacTCP and a certain new implementations of Unix
nameservers. The problem should be fixed by upgrading to MacTCP
2.0.6.

It may be that some other computer is using your manually assigned IP
address. When MacTCP loads, it in effect says: "host with IP number
so-and-so, please respond". Your Mac's IP address is used in that
query. If there is no answer, all is well. But if something out there
responds, MacTCP correctly assumes that there is a conflict in IP
numbers, and returns an error code which most applications then
translate to a less-than-helpful message like "Error opening TCP
drivers - possibly no dynamic addressing". Talk to the local
administrator to verify that the address you were given is not used
by anyone else.

Different applications translate MacTCP error codes into different
messages. Some just display the error number, which isn't very
helpful. See Appendix D for a partial list of those codes, gleaned
from the MacTCP Developer's Kit distributed by Apple.

Much of the above can be diagnosed with a utility MacTCP Watcher,
written by Peter Lewis, and available from most Mac archives.


4. Drastic measures

o  If you are still having problems, trash the following from the
hard disk: MacTCP, AdminTCP, MacTCP Prep, and MacTCP DNR. These files
are found in the System Folder proper (in pre-7 Systems) or in
various subfolders, such as Control Panels, Preferences and
Extensions. Reboot and install fresh network drivers, then install
MacTCP and configure it carefully again. Reboot one more time and see
if all this helped. If problems persist, consider trashing not only
the MacTCP files, but also the System, Finder, all network drivers
and control panels (AppleTalk, EtherTalk, Network), and reinstalling
fresh copies. This is almost certainly an overkill, but in some cases
it is also a recipe for instant happiness. Of course, you'd better
first back up all the files which seem important to you, such as
non-standard extensions or fonts, which will get erased in the
process! Then install a fresh system.

o  Disable all system extensions and non-essential network-related
Control Panels, especially those which may be requesting network
services at boot time (such as Network Time). Again, this probably
isn't necessary, but who knows... As is well-known, system extensions
can produce mind-boggling conflicts. When you succeed in making
MacTCP work without them, you should later reinstall them one by one,
checking - say - telnet after activating each of them. If MacTCP
conks out, you'll know the culprit! If that happens, please publicize
your findings, or at least send a note to me.

o  Remember that in case of a dial-up connection, your Mac is only
one piece of the puzzle. The other end, i.e. your provider's modems,
routers etc. also have to be properly configured, which might not be
the case. Moreover, the provider may be unwilling to admit that
something is wrong -- it's been known to happen. You may have to
switch to another one. Shop around, and stick to the reputable
Internet businesses.

If these radical surgeries still don't work, donate your Mac to a
local school, get another one, and begin life afresh.

5. Tricks, hints, and caveats

If you need your Mac's Ethernet hardware address for debugging
purposes or simply for your records, you can get at it by holding
option down while clicking the "Ethernet built-in" icon in the MacTCP
panel. Another method is to log on to a nearby Unix machine, do a
"ping" to your Mac's IP address, and then tell the Unix host to list
its "ARP cache": arp -a on most systems. The hardware address will
appear next to your Mac's name as 12 hex digits divided into pairs.
For the ping to succeed you must first start up some Internet
application on the Mac.

Remember that Ethernet and Token Ring handle hardware addresses
differently; if the Unix host and the Mac are on those two different
types on networks, you need to translate each pair of hex digits into
8 binary digits, reverse their order, and translate the whole shebang
back into 12 hex digits to get the real hardware address.

Older Macs, notably the Plus, become overworked while running System
7 (more precisely, the newest versions of AppleTalk) and MacTCP 1.1.
Make sure to install a new version of MacTCP.

Sometimes the physical link icons (usually the "LocalTalk built-in"
icon) mysteriously disappear from the old versions of the MacTCP
control panel. Make sure you are using a current MacTCP.

Don't disregard the physical connection. I've seen several reports of
strange problems which were eventually traced to a bad wire or
transceiver. Some of Apple's "FriendlyNet" cables for use with the
Quadras were involved. Borrow a working transceiver and cable from
someone and try it before blaming everything on the software.

Are things messed up, and you are stuck? Make sure to contact the
vendor of the network adapter. There may be a problem which they know
about. You may need to get an updated driver from them.

It was reported that the Apple cache card (for the IIci) used to
cause problems with MacTCP and a lot of other things. Scream for a
replacement!


6. Using AdminTCP

If you are responsible for configuring MacTCP in your department or
organization, in some cases you will want to lock the settings you
have entered, so that users with itchy hands will not fool around
with them.

Open the AdminTCP panel (even an old version should work with a new
MacTCP, but of course it is best to get a current one!) In the inner
panel click the three checkboxes which lock the address, and click
the "Protected" box. Close the panel and reboot right away.

Remember to trash AdminTCP from the user's disk afterwards, so he
won't be able to unlock the settings, unless you trust the user not
to mess things up intentionally.

If the prospective user is a TCP/IP sage, you should of course leave
things wide open for him to play with the little buttons during long
winter nights.

There are some other permutations involving, for example, locking
just the network part of the address, but leaving the subnet and node
numbers accessible. Please read the manual!


7. More about nameservers

Going into the details of the Internet Domain Name System (DNS) would
make this document twice as long, so we will stick with the basics,
explaining what went on when we filled in the MacTCP "Nameserver
information" fields. The Domain Name System is used by computers to
convert the human-friendly names such as "rs.internic.net" to numeric
addresses (IP numbers) such as 198.41.0.5. Internet computers also
use this system to "reverse-map" numeric addresses, i.e. to verify
that your numeric address does correspond to a name which is
recognized by the DNS. A part of MacTCP, the "resolver", is
responsible for doing all this on your Mac.

If your network is connected to the Internet, your computer lives in
some well-defined "domain". In my case, it is math.niu.edu, and a
machine with address 131.156.3.3 is providing name service for that
domain. I thus enter "math.niu.edu." (do not use quotes) in the Domain
field, and 131.156.3.3 in the Server field next to it. I also click
the Default button. This informs MacTCP that my computer is in the
math.niu.edu domain, so when I tell my Mac to telnet to "sunflower",
it will query the nameserver about the address of
"sunflower.math.niu.edu".

If the local nameserver doesn't keep a large table of addresses, or
if it is less than reliable, you will probably want to add some
backup servers (this is generally a good idea). In particular, one or
more Domain fields could contain the period alone to handle the "root
domain", i.e. the entire Internet, with the address of a big,
reliable machine next to it.

Clicking the "default" button by no means guarantees that this server
will be consulted first; MacTCP first contacts those nameservers
listed in the control panel which seem to match the domain name
included in the query - and only if that fails, the default server is
asked as a last resort. However, all domain name queries should
generally go to your local nameserver first. You may want to enter
your local nameserver's address in the second row as well, specifying
the root domain (period) in the first field.

If the resolver is given a name without periods in it, e.g.
"sunflower", it will tack on your default domain, and send out a
query for "sunflower.math.niu.edu". If there is no computer by that
name, the query will fail.

If the name contains periods, MacTCP considers it to be a "fully
qualified domain name", and tries to match the tail of it with one of
the domains you entered in the MacTCP panel. For instance, a query
for "sunflower.math.niu.edu" will go to the nameserver specified for
domain math.niu.edu (if any), then -- if that fails -- to the
nameserver for niu.edu (if any), and finally to one of the servers
for the root (.) domain.

There is currently no support for the so-called "partially qualified
names"; e.g. "sunflower.math" will _not_ get anything tacked on, even
though you may hope that MacTCP will be smart enough to try adding
"niu.edu" to it.

A small text file called Hosts can be put in the System Folder
proper; it lets you enter additional information which MacTCP uses
when it carries out the name resolution process described above. For
example,

clinch.math.niu.edu      IN   A   131.156.3.3
math.niu.edu             IN   NS  clinch.math.niu.edu
rs6000.cmp.ilstu.edu     IN   A   138.87.1.2
risc                     CNAME    rs6000.cmp.ilstu.edu

in the Hosts file tells MacTCP that clinch.math.niu.edu has address
131.156.3.3, that it is a nameserver for my domain, that
rs6000.cmp.ilstu.edu has address 138.87.1.2; since I connect to it
often, I want my Mac to use rs6000.cmp.ilstu.edu whenever I say
"risc." (if there were no dot, MacTCP would start looking for
rs6000.math.niu.edu!).

A Hosts file on a Mac tends to be neglected or overlooked, unlike --
say -- the NIS hosts file on your main network server. Keep this in
mind when deciding whether to put a lot of information there. When IP
addresses change, it may come back to haunt you, since you may not
even remember it's there. It's better to rely on a reliable, properly
configured and maintained nameserver for your domain.

A bug in MacTCP 2.0.4 discovered by Sylvia Elliott causes the
resolver to fail on CNAMEs in the Hosts file which contain digits.
MacTCP 2.0.6 may have fixed this.

The newest versions of the resolver also disallow host names which
contain underscores. This has caused significant controversy; even
though this is "correct" behavior according to Internet standards,
older implementations have not enforced this restriction, and there
are several computers out there with such names. Until they disappear
you will have to use numeric addresses to reach them.

For a list of specifications allowed in the Hosts file, see the
MacTCP manual.

After modifying the Hosts file or the nameserver information in the
MacTCP control panel, make sure to trash the MacTCP DNR file, and
reboot right away.


8. Minimal setup

It is often useful to construct a minimal network consisting of two
Macs running TCP/IP: either to test an application being written, or
just to see this side of Mac networking in action. Here is what you
should do to get such a mini-net running.

Connect the Macs with a LocalTalk cable (PhoneNet boxes at each end
recommended for good reasons, even though a simple printer cable will
do for those who like risks). Ethernet-ready Macs can be connected
with a short piece of coax cable (good terminators at each end!), or
a twisted pair cable. Do not use a hub-to-adapter cable! it won't
work. You have to swap the send/receive pairs as follows:

  RJ-45 plug pins
   1 -------- 3
   2 -------- 6
   3 -------- 1
   6 -------- 2
On each Mac put a file called Hosts in the System Folder; in each of
them type:
testa     IN   A    244.244.244.1
testb     IN   A    244.244.244.2
Avoid using numbers in host names, i.e. don't try test1 or mac15. And
remember that you have to get official IP addresses before you  hook
the Macs up to the outside world.

In MacTCP set the appropriate link icon (LocalTalk or Ethernet),
addressing to manual, gateway to 0.0.0.0, and leave the nameserver
information entirely blank.

In the "outer panel" set the IP address to 244.244.244.1 on one
computer, and to 244.244.244.2 on the other one. Reopen the "inner"
MacTCP panel and verify that subnet mask is 255.255.255.0, and that
network class became C.

Enable AppleTalk in the Chooser, reboot, and you should be up and
running. Install some clients and servers on the Macs (Fetch/FTPd, a
Web client and httpd, and so on) and try them out.

Since MacTCP still has problems with various timing parameters, on a
network like this where delays and transmission times are weird you
may occasionally see errors such as "No connection in place".


V. Applications

There are many commercial programs which use TCP/IP connectivity
(InterCon Systems family of networking applications, VersaTerm from
Synergy Software, MacX from Apple, just to name a few). I will not
review them here because I have had little or no experience with
them. Let the vendors speak for themselves.

The list of public domain or shareware software which follows is far
from complete; moreover, new applications appear very often, and we
cannot possibly keep it up to date. We will focus on a few most
important packages which should get you started. See Part VI for
information on obtaining this software.


1. Terminal emulation

There are currently two primary free programs which let the Mac
connect to other hosts as a terminal using TCP/IP (telnet): NCSA
Telnet and its derivative, tn3270.

The first one is being developed at the National Center for
Supercomputing Applications in Urbana-Champaign. It emulates a vt100
terminal and provides some Tektronix graphic terminal capabilities;
it also implements an ftp client and server, but support for this
will disappear in future versions.

The second, tn3270 written at Brown University, is a variant of
Telnet which provides the IBM 3270 terminal emulation. It also
supports file transfers and printer sessions, given the right
software installed at the big iron end.

NCSA Telnet used to come in two versions: one which relied on MacTCP,
and one which included built-in TCP/IP drivers. Starting with Telnet
2.5, the two have been merged into a single package.

You may also want to try a third package, Comet from Cornell
University, which is still available from some ftp archives. It can
be used over a network with MacTCP, or with an ordinary modem
connection.


2. E-mail

There are several schemes in which a Mac can access Internet mail.
The crudest way, of course, is to telnet to a host on which you have
an account, and use that host's mail facilities. Another is to keep
using whatever mail system you have on the AppleTalk network (e.g.
QuickMail or Microsoft Mail), and then provide a SMTP gateway which
will translate it to Internet mail; this tends to be expensive,
sometimes unreliable, and may be difficult to maintain.

By far the most popular and convenient system is the client/server
method, in which one computer uses its powerful mail software and
provides service to clients such as Macs or PCs. Macintosh users have
the good fortune of being able to use some excellent mail clients
which work on a Mac. Eudora written by Steve Dorner leads the pack
(in my humble opinion). Non-commercial versions are still maintained
and supported by Steve, even though innovations and functional
improvements find their way into the commercial package first.

Eudora and other similar clients allow the user to read, compose, and
edit mail on the Macintosh desktop; it can print mail, save messages
as Mac files, and attach Macintosh-specific files (say, formatted
Word documents or even applications) to the letters using one of the
encoding schemes, e.g. BinHex (see Appendix A). When it's time to
process mail, Eudora contacts the server, uploads messages waiting to
be sent and downloads those which the server received for you. The
(supposedly) well-maintained and well-connected server computer
handles the rest, so you don't need to know anything about Unix or
any other alien operating system.

The current versions of Eudora also support MIME (Multi-purpose
Internet Mail Extensions), a standard for transferring images,
sounds, international characters etc. via the ASCII-oriented Internet
e-mail.

Seting up a POP server on most Unix computers is rather trivial, but
it does require superuser privileges. If you use a VAX with VMS, and
some TCP/IP package is already installed, chances are that it
includes a POP server. There is also a public domain POP3 server for
VMS available from Indiana University, which a dear friend of mine, a
computer semi-literate, got up and running without much grief. Talk
to your local system administrator.

One of the selling points of the POP protocol is that several decent
clients are also available for DOS and Windows computers (NuPOP,
PC-Eudora from Qualcomm, etc.). Moreover, most of those clients can
send and receive attachments using standard encoding; in many cases
it is possible -- say -- to save a Word document as a WordPerfect DOS
file on your Mac, attach it to a letter in Eudora, and send it to
someone who is stuck with a WordPerfect Office mail system behind a
Novell SMTP gateway...

In case you don't have a bigger machine which may be used as a POP
server, don't worry; your Mac can be made into a full-blown SMTP
mailer, and it then behaves like any other "real" Internet mail node.
Glen Anderson's MailShare does just that, in addition to providing
POP service for other Macs. If all you want is SMTP service for the
individual Mac, you can try Lee Fyock's LeeMail, but MailShare is
probably a better choice at this time. Naturally, a Mac configured as
an independent Internet mail host had better have reliable
connectivity with the world at large (and a properly configured
Domain Name Resolver).


3. FTP

Just like Eudora seems to be the mail client of choice, Fetch by Jim
Matthews reigns in the FTP area. Older clients include the HyperFTP
stack, and the orphaned (but still useable) XferIt. There is also an
FTP server that runs on Macs, FTPd by Peter Lewis. Anarchie is a very
convenient marriage of an Archie client (which searches lists of
software on anonymous FTP servers) with an FTP client.

As we will explain in Appendix A most Mac files you download will
require further processing. Fetch allows you to do this painlessly if
you install gadgets such as StuffIt Expander and MacGzip on your
disk, and configure things so that incoming files are automatically
decoded/decompressed by them.

When using FTP from a Mac, you should realize that many anonymous FTP
sites do not allow connections from hosts which are unknown to the
Internet nameservers. To connect to such nodes, your Mac's IP address
has to "reverse-map" to a legal Internet name, like
mac1.math.niu.edu. The system administrator of your nameserver
computer might be willing to enter your address in his database.


4. Network news

There are several Mac applications designed to let you access Usenet
news: Newswatcher and Nuntius are probably the most popular. I have
not experimented with Nuntius, so I can only quote second-hand
information: at least one of my correspondents swears by Nuntius as
"the best newsreader I have seen on the Mac by far".

Reading Usenet articles usually involves downloading humongous lists
of articles over a slow connection such as overloaded LocalTalk, or
worse -- a modem link, keeping track of read items, and so on. This
is not for the faint of heart. Many people still stick to the
old-fashioned method of logging on to a bigger host and reading news
there. But when it works, it's worth it! You can finally organize the
saved articles on your own disk, use your favorite word processor to
write replies, etc.

News clients require an address of a nearby friendly NNTP server. The
server needs to be friendly in the sense that it must recognize your
Mac as a host which is allowed to post news. As with FTP, this
usually requires having a valid domain name, and the server must have
been configured to accept uploads from your computer. Even though
some servers allow free read access and only limit posting, the Mac
clients will usually give up without explanation unless they are
granted both permissions. This causes a lot of confusion among novice
users, who then complain about "broken newsreaders".


5. Internet Gopher

The Internet Gopher is a system of "gopher servers" on various
Internet hosts which can be contacted by a gopher client, passing the
connection on to other servers in a way transparent to the user. The
data on the servers are presented as menus, which can be text or
binary files, links to ftp archives or Usenet news servers, or
finally pointers to other gopher servers. It is a very convenient
mechanism for putting the bewildering spectrum of Internet services
under one roof. The principal Mac client, TurboGopher, has been
created by the designers of the gopher system at the University of
Minnesota. There is also a gopher server which runs on Macs.

Gopher has become one of the standard ways of providing access to
distributed information such as campus directories, WAIS servers,
on-line publications, etc. It is also the preferred method of
accessing many of the anonymous ftp sites, such as the sumex archive
at Stanford.


6. World-Wide Web

In the 70's FTP was "it". In the early 90's it was the gopher. In
mid-90's, it's WWW, or "W-cubed", or World-Wide Web. Visionaries at
the European CERN laboratory in Geneva realized that hypertext ideas
(conceived quite a long time ago) could be combined with Internet
connectivity to provide a uniform access to resources "out there".

The idea really took off when programmers at NCSA released Mosaic, a
client application which allowed Unix machines, Macs, and PCs to
access WWW servers in a way that showed the stunning capabilities of
the system. After connecting to a WWW "page" you see text, links to
other parts of the document, icons, images, links to other pages
thousands of miles away; you can click on an icon and hear a sound;
click on an underlined address and send a note to someone; click on
an electronic newspaper's masthead and see the editor's face. Access
to other protocols such as FTP or telnet connections is integrated
into this paradigm.

The development of the Web has forced some other standards to evolve
rapidly. The "uniform resource locators", or URLs, are the new
language used to specify where a given item lives in the net
universe: e.g. ftp://ftp.math.niu.edu/pub/mac/doc/mactcp.txt means
"connect by FTP to the host ftp.math.niu.edu, and retrieve the file
mactcp.txt in the directory /pub/mac/doc". Together with MIME, WWW
has helped the evolution of standards for exchanging complex
documents between different systems.

Documents written in the WWW HyperText Markup Language (HTMLs for
short) are very flexible; they can be used to provide a help system
for local users, a tutorial for novice photographers or origami fans,
or a sound-enhanced catalog of music recordings. They are also quite
"expensive" in terms of the network load: WWW pages tend to be full
of images, sounds and icons comprised of hundreds of kilobytes of
data, sometimes causing unprecedented congestion on info-ways we all
use. Let us hope that this will soon cause an equally dramatic
increase in the bandwidth of the Internet infrastructure.

Two Mac clients dominate the field: NCSA Mosaic, and Netscape from
Netscape Communications Corporation. Netscape is a commercial
product: please make sure you read the accompanying license. A third,
MacWeb, is also gaining popularity. You can turn your Mac into a WWW
server with a Mac HTTP daemon application (e.g. httpd or MacHTTP),
available from many archives.


7. Miscellaneous gadgets

Even if you install only the basic Internet programs, you will notice
that configuring them all is quite a balancing act. At the same time,
many of them share certain parameters: your name, address of a mail
server, preferred e-mail address, and so on. The program
InternetConfig has been created to help you organize such parameters
in one place.

Older versions of these notes listed a number of specialized Mac
applications which use MacTCP in this section. Since this category is
so fluid, with some programs being abandoned, and new ones showing
up, I feel it would be unfair to single out just a few packages I
like.

Instead, I will single out one person: Peter Lewis, who has been busy
creating useful MacTCP applications for some time now. They include
an FTP server, a MacTCP debugging application, an intelligent
"archie" client for searching and accessing FTP archives, a "talk"
program, and so on. I feel that Peter's work, which has helped many
of us enormously, deserves special recognition and support.


VI. Sources

There are some excellent sources of background information on the
Internet in general, and TCP/IP in particular. Two classics which
come to mind are:

"Zen and the Art of Internet" (by Brendan Kehoe),
"Hitchhiker's Guide to the Internet" (by Ed Krol).

Both can be obtained by anonymous FTP from ftp.uu.net (directory
/inet/doc). The files are Unix-compressed, so they should be
downloaded using binary mode and then decoded with a Unix-style
uncompress application. See the next section for a primer on ftp.
Note that newer editions of "Zen" are only available commercially.

Several FTP sites have copies of most newer Requests For Comments
(RFCs), documents which establish Internet standards. Try
rs.internic.net or nic.switch.ch. To get started download the files
rfc-index and fyi-index. There is no substitute for reading RFCs
(painful as it may be...)

A popular and very complete paper reference is "The Whole Internet
User's Guide and Catalog", also by Ed Krol, published by O'Reilly and
Associates.

A three-volume series "Internetworking with TCP/IP" by Douglas Comer
is published by Prentice Hall, and contains everything you have ever
wanted to know about the protocol that makes the Net tick.

Frequently Asked Questions (FAQ) files are the accepted method of
answering "newbie" questions; even if you consider yourself an
experienced 'Netter, you may want to check them out. The most
relevant one is available by FTP from rtfm.mit.edu, in the directory
/pub/usenet-by-group/comp.sys.mac.comm.

The main archive of public domain and shareware Mac software is
maintained on sumex.stanford.edu. There are several "mirrors" which
you may want to try when sumex is too busy to let you in, e.g.
nic.switch.ch or src.doc.ic.ac.uk, but they are often just as busy
as sumex. Another fairly complete Mac archive is on
mac.archive.umich.edu.

Adam Engst keeps a comprehensive collection of Mac communications
software on ftp.tidbits.com, in the directories /pub/tidbits/tisk and
/pub/tidbits/select. For announcements of new versions of this
software, WWW users should see http://www.tidbits.com/tidbits/. If
you are looking for a communications package, or an init string for
your modem, or a SLIP dialup script, those are the places to look.
You can also send mail to [e-mail] to inquire about the
current status of his "Internet Starter Kit" book.

Official MacTCP-related files released by Apple can be obtained by
anonymous ftp from ftp.info.apple.com and from seeding.apple.com; Web
fans can try http://www.info.apple.com. Note that Apple likes to
distribute some of its software as "disk image" files. Such files
have to be loaded into an application such as DiskCopy (available on
ftp.info.apple.com in /dts/utils) or ShrinkWrap, which can then
produce exact copies of an original master floppy disk. Moreover,
many files on Apple archives are prefixed with the lengthy
lawyer-speak section, which can justifiably confuse some BinHex
decoders; after downloading such .hqx files, use an editor to cut out
the legalese before de-BinHexing.


Here are pointers to software which is found in less obvious places:

Eudora:           ftp.qualcomm.com
GopherApp:        ftp.bio.indiana.edu in /util/gopher/gopherapp
MacDump:          bbn.com in /pub/MacDump
NetNews:          ftp.bio.indiana.edu in /util/mac
Netscape          ftp.mcom.com
POP servers:      ftp.qualcomm.com, ftp.cc.berkeley.edu
tn3270:           brownvm.brown.edu
TurboGopher:      boombox.micro.umn.edu in /pub/gopher
VMS POP server    ftp.indiana.edu in pub/vms/iupop3

This should keep you busy for now...


Appendix A. An FTP Primer

1. Downloading text files

Use any account available to you on a well-connected host. Type "ftp
ftp.math.niu.edu". When asked for a username, reply "anonymous"; give
your mail address as password. In 9 cases out of 10, archives such as
this one will accept "ftp" in place of "anonymous", which is meant as
a favor to the new spelling-challenged generation. You will also
discover that many sites will accept any password at all, but let's
be nice to those folks who specifically ask for the real id.

Enter "cd /pub/mac/doc", and then "get ftp-primer.txt". When you see
"Transfer complete", type "quit" and read the file you just
downloaded.

After becoming skilled in using ftp, download some more text files
from the /pub/mac/doc directory on ftp.math.niu.edu:

help/accessing-files.txt
report/how-do-i-find.txt

Many more such files are on sumex.stanford.edu, in the directory
/info-mac/comm/info (most of them are mirrored on ftp.tidbits.com in
/pub/tidbits/tisk/info).


WARNING!!!
The minute you start downloading files from the network, you become
more susceptible to viral infection than before. I strongly suggest
that you should first get and set up the wonderful free virus
checker, Disinfectant. Its home is ftp.acns.nwu.edu, in directory
/pub/disinfectant; it can also be found in many other places, e.g. on
sumex.stanford edu in the directory /info-mac/virus. You may then
want to send its author, John Norstad, a nice thank-you note: we all
owe him a great deal! If you have access to Usenet news, make it a
habit to monitor the comp.sys.mac.announce group: it is probably the
most reliable source of information about newly discovered viruses.


2. Peculiarities of Mac file transfers
Macintosh files differ from files on most other machines in that they
consist of two parts. One contains data (text, executable program),
and the other - resources (icons, the file's creator code, etc.) I'm
simplifying a little, but never mind. This complicated structure
prevents us from sharing such files directly over the network.

Moreover, there is only one language which practically all computers
understand: the ASCII code (plain text). Even though this isn't a
terribly elegant solution, we simply bring everything to this lowest
common denominator to assure compatibility. For example, in order to
send a file to someone by the current e-mail systems, it has to be
somehow encoded into an ASCII file.

The Mac community has pretty much agreed on a common standard for
doing just that: BinHex. BinHex swallows a Mac file, icons, file
creators and all, and converts all that into a plain text file filled
with something that looks like garbage; it also performs the reverse
procedure. So you need BinHex.

There is one obvious difficulty, however: how do you get a BinHex
decoder (a Macintosh application!), when you don't have BinHex? You
will also need software which will somehow let your Mac do FTP. The
easiest way to "bootstrap" yourself is to simply get a copy of such a
beast from a local Mac guru or a Mac User Group. If you're lucky, you
will lay your hands on a utility which can not only transfer files,
but also un-BinHex them -- such as Fetch, or TurboGopher. You can
then tell it to connect directly to, say, sumex, dowload the
interesting BinHex'ed files, and decode them while they arrive.

Another way is to get NCSA Telnet, log on to a friendly Internet
machine, download the applications you need to that computer in
*binary* form (e.g. the file binhex4.bin available on sumex in
/info-mac/util) using the binary mode in ftp. Then connect back to
your Mac using the Telnet FTP server and put the files on the Mac
using the MacBinary mode... It sounds (and is) a bit complicated, but
remember - this convoluted process is necessary only in the very
beginning.

Once again, we have just licked the surface of this topic here. For
more information, see the file /info-mac/report/ftp-primer.txt on
sumex.stanford.edu.


3. What next?

When you have learned how to download Macintosh executable files,
it's time to go hunting for specific applications. Use the hints
given above to "bootstrap" yourself. The possibilities under your
fingertips are something that your parents didn't even dream about.

You may want to start experimenting with Gopher, and WWW at this
point. Most software available via FTP can also be downloaded using
those tools, which often let you find things more quickly and easily.
We have already mentioned another application, Anarchie, which is
invaluable in locating hard-to-find files on FTP servers.


4. Let's end with a short sermon...

Many of the applications mentioned above are NOT in public domain.
They are either shareware, or there are restrictions on their use
and/or distribution. PLEASE PAY FOR SHAREWARE YOU KEEP!!! Author's
address can almost always be found by pulling down the Apple menu and
selecting "About..." Let's keep this wonderful, affordable software
alive!


Appendix B. Mac networking: mini-tour

In the networking world, it is easy to drown in the alphabet soup and
the sea of obscure terms. But understanding the process by which
computers communicate helps troubleshoot problems. We will go through
some elementary information in this appendix. Things may get a bit
confusing, and you may want to read what follows two or three times
until it makes sense...

For two digital devices to talk to each other, there must be a
physical connection between them (a wire, optical fiber, radio link,
etc.) and an agreement as to the logical organization of the
information. In computerese, such mutual understanding is usually
called a "communications protocol".

Apple's Macintoshes use a "native" set of protocols, collectively
known as AppleTalk. The physical aspect of AppleTalk is, very simply,
the kind of wires the device uses. If you stick a little round
connector into the printer port of your Mac, or in the jack in your
LaserWriter, you are using AppleTalk over Apple's original slow
wiring, i.e. LocalTalk. Almost nobody uses that now -- even Apple's
own network uses Farallon's Phonenet system, but that is a technical
detail. You are on LocalTalk.

If your Mac has an Ethernet card or external adapter attached, you
will be using AppleTalk on a physical Ethernet network; that is
called EtherTalk. Similarly, if you install a Token Ring adapter, the
incarnation of the AppleTalk protocol you are dealing with is called
TokenTalk.


The logical layer of AppleTalk handles details such as how two Macs
can discover each other on the network, how individual nodes are
uniquely identified, what should a Mac say to a printer or an
AppleShare file server when it wants to use it, and so on. The
devices you see in the Chooser (LaserWriters, file servers, or
routers such as Netway or SNA/ps) are all AppleTalk devices. The
beauty of AppleTalk is that you don't really care what physical
method you use. You may see a printer on LocalTalk, or a LaserWriter
IIg on Ethernet, or a Netway box on Token Ring -- it doesn't matter.

But the nitty-gritty of how the actual network operates does vary
from one kind of wire to another. The computer has to behave
differently on each kind of network, but of course you don't want to
know about that! Enter "network drivers": low-level pieces of system
software which take care of that. When you put in an Ethernet card,
you need to install the EtherTalk drivers in your system. Same with
TokenTalk drivers. It's like speaking with someone over the phone, or
on a walkie-talkie. The principle is different, but the message is
the same.


There are more and more ways of making non-Apple devices speak
AppleTalk: that's why there are MS DOS computers on LocalTalk
networks, Novell AppleShare servers, and you can configure your Sun
Sparcstation to print on an Apple LaserWriter. The Internet world,
however, doesn't know the first thing about AppleTalk. It only
understands the collection of protocols known as TCP/IP. What does
TCP/IP have to do with AppleTalk? The answer is "not much", and
"nothing" most of the time. Putting a Mac on a TCP/IP network is like
dumping an Englishman in the center of Beijing: there is a language
barrier.


MacTCP, the gadget we are discussing in this document, allows Mac
applications to use network interfaces -- such as the built-in
LocalTalk port or an Ethernet card -- to transmit and receive data
packets which contain TCP/IP information, and hence to communicate
with the millions of other TCP/IP computers on this planet.

Just like Apple came up with specifications for sending the
high-level (AppleTalk) data using the various low-level,
network-specific "transport protocols" (Ethernet, Token Ring etc.),
the Internet has standards for sending the high-level TCP/IP data
using the low-level network mechanisms. Ethernet is the best choice,
since the Internet protocols reached their maturity on Ethernet, so
those standards are well-established.

Apple adopted a certain way of sending TCP/IP data wrapped inside
LocalTalk packets, and MacTCP knows how to handle this. It puts
("encapsulates") TCP/IP information into a normal LocalTalk packet,
and sends it out. That packet makes absolutely no sense to any
AppleTalk device (it looks like it has garbage inside), except those
which use MacTCP to do the reverse decoding.

A standard for transmitting TCP/IP data in Token Ring packets has
also existed for quite some time. But MacTCP did not know about it,
until Apple released an add-on "MacTCP Token Ring Extension", which
-- again -- takes a TCP/IP packet and beats it into shape before
sending it through a Token Ring card.


To make things more interesting, MacTCP used on Ethernet (or Token
Ring) is capable of two different behaviors: it can take the TCP/IP
data and spit it out unadorned, according to the usual, world-savvy
IP-on-Ethernet or IP-on-Token Ring recipe. But it can also be set to
use EtherTalk (respectively, TokenTalk), which means that it will
activate the wrapping/unwrapping AppleTalk filter between the network
interface and the application software! The general idea is *not* to
use EtherTalk or TokenTalk in MacTCP. The reason should become clear
soon.


To summarize, here are some scenarios. (a) Mac on Ethernet, MacTCP
correctly installed, "Ethernet built-in" set in the MacTCP control
panel; (b) Mac on Token Ring, MacTCP installed, the Token Ring driver
installed and configured properly, TokenRing selected in MacTCP. All
is peachy. A TCP/IP-aware application on the Mac (such as NCSA
Telnet, etc. -- see Part V) wants to communicate with a Cray at the
Space Station "Freedom", which by the time I finish this will be in
orbit. It tells MacTCP to send out a Telnet packet, MacTCP translates
it into the standard format for Ethernet or Token Ring, some gateways
down the road convert it to the TCP/IP over radio waves form, the
packets gets to the Cray, it says "Aha! we've got a hacker trying to
log in here", and so it goes.

Now for something more mundane. (c) Mac Plus on LocalTalk, MacTCP
installed, "LocalTalk built-in" selected in the MacTCP panel (the
only possible choice!). A TCP/IP "datagram" goes out after being
wrapped into an AppleTalk packet! Now, the LocalTalk is no doubt
connected to the outside world one way or another. If that's done
using a relatively unsophisticated device, it will take the data and
simply convert it to an equivalent EtherTalk, TokenTalk, or whatever
packet. That one goes out allright, gets up to the Cray, but it now
says: "Phooey, that's something I don't understand! It has some
strange stuff inside! Let's quickly drop it on the floor." The reason
is that most Internet hosts, like our Cray, are not instructed by
their software to go deeper inside the packet and actually recognize
that it was TCP/IP information wrapped inside AppleTalk... and why
should they bother? What is needed is a more sophisticated gateway
between the LocalTalk and the outside network.

Scenario (d): Mac Plus on LocalTalk sends a TCP/IP-in-AppleTalk
packet which is directed towards a "DDP-IP gateway", such as the
Fastpath, Gatorbox, EtherRoute/TCP, etc. The gateway's software is
smart enough to look under covers and see what is hiding inside. If
it sees TCP/IP data wrapped inside AppleTalk, it strips the outer
layer and passes the raw IP information in the standard format to the
Ethernet network. All is well again! LocalTalk-to-Ethernet gateways
like that are common, but equivalent ones for Token Ring are still
scarce and expensive.

How about (e): just like in scenarios (a) or (b), except MacTCP is
set to use EtherTalk (or TokenTalk). Now regular TCP/IP packets will
not be coming through -- MacTCP simply ignores them! It expects
AppleTalk packets only. It will be able to communicate with the Mac
Plus in (c), but not much else. So let's just forget it and stop
here...


Appendix C. Dial-in access

1. ARA

In our personal opinion, the most elegant way to connect a Mac to a
TCP/IP network is AppleTalk Remote Access (ARA), a commercial product
of Apple Computer, bundled with PowerBooks, and sold as a separate
product.

ARA uses the Communications Toolbox (built into System 7, and
installable in System 6.0.x) to ship AppleTalk packets over a modem
to an ARA server, which is presumably connected to a "real" network.
MacTCP in turn uses the AppleTalk protocol to transmit "wrapped"
TCP/IP packets (if it is configured to communicate via AppleTalk).
This results in a two-stage translation: TCP/IP-to-AppleTalk, and
AppleTalk-to-modem. The data have to be decoded by a reverse process
at the other end.

This explains the only major drawback of ARA: speed. A 2400 baud
modem is next to unusable in this configuration. But a 9600 baud or
faster connection provides decent response even with the additional
IP encapsulation.

The server Mac, whether it's on Ethernet or LocalTalk, spews out
AppleTalk packets, from which the TCP/IP information has to be
reconstructed by an IP gateway. If you don't have a gateway such as
the Fastpath, GatorBox, EtherRoute, or similar, you can't use ARA for
TCP/IP access to the network.


2. SLIP and PPP

The most popular dial-in connection schemes, however, employ
protocols developed specifically for that purpose, such as SLIP or
PPP. A public domain MacPPP driver is available from several Mac
archives, and is quite serviceable. There are also commercial PPP
drivers. SLIP is available on the Mac in the form of several
commercial offerings. More information on SLIP software can be found
on ftp.bio.indiana.edu in the directory /util/slip. Pat Hoepfner also
suggests reading two documents at "ftp.uu.net" in the
"vendor/MorningStar/papers" directory. These unix compressed
PostScript files are named "sug91-cheapIP.ps.Z" and
"ppp-white-paper.ps.Z".

A suitably configured SLIP connection gives the dial-in Macintosh all
the functionality of a node attached directly to a TCP/IP network,
even though it is of course usually much slower, even with the modern
28,800 bps modems. Configuring reliable dial-up connection is not a
trivial matter, because the modem and the SLIP or PPP software add a
new layer of complexity. One universal rule seems to be that with
fast modems you have to: (a) use a "hardware handshaking" modem
cable; (b) set your software so it uses hardware (CTS or RTS & CTS)
handshaking; and (c) initialize the modem so it has XON/XOFF
handshaking disabled.

In most cases you will set MacTCP to server addressing when using
serial line connections (unless your provider only supports static
address assignment). Most of the MacTCP parameters (gateway, subnet
mask, etc.) are either irrelevant here, or will be set by the SLIP or
PPP driver at connection time.

Let's now look at two most popular serial IP drivers for the Mac:
MacPPP and InterSLIP. They are both freely accessible from on-line
sources. I don't know much about modems, and I use SLIP and PPP only
occasionally, so the sections that follow are not likely to help you
troubleshoot difficult problems. Adam Engst's book mentioned in Part
II.2 has much more information on the subject. You can also receive
some help by sending an e-mail note to [e-mail].


3. InterSlip

Start up InterSLIP Setup. Create a new setup using the File menu.
Double-click on it to open it. Set the modem parameters, remember
about hardware handshaking. Opening InterSLIP Setup will have created
a folder InterSLIP Folder:Gateway Scripts inside the Preferences
Folder in the System Folder. Create your connection script, which is
a text file (see simple example below), and put it in that folder.
You should now be able to select that file in the Gateway setting in
InterSLIP Setup.

You can now set other parameters. I have the nameserver entered
manually in InterSLIP, RFC compression on, hardware handshake,
Hayes-Compatible modem (I use an AT&T Dataport 14.4). IP address and
MTU Size are empty; they will be obtained from the SLIP server at
connection time. Username and password will have to be set to values
you were given by the SLIP administrators, or left blank if the
server does not require them.

Here is a simple connection script which should work with a server
that doesn't do user authentication. Most real-life situations will
call for a more complex one.

!
@originate
note "Waiting for prompt"
matchclr
! edit this to match the prompt your server gives
matchstr 1 4 "TSERVER>"
matchread 50
note "Gateway not responding!"
exit -1
!
@label 99
pause 1
sound
pause 60
exit -1
!
@label 4
note "Requesting SLIP"
write "slip\13"
matchstr 1 5 "Entering SLIP mode."
matchread 120
note "Cannot invoke SLIP mode"
jump 99
!
@label 5
matchexp 1 6
"[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*\\."
matchread 120
note "No IP address given"
jump 99
!
@label 6
setip "^0"
matchclr
matchexp 1 7 "[0-9][0-9]*"
matchread 120
note "No MTU value"
jump 99
!
@label 7
setmtu "^0"
exit 0


4. MacPPP

If you have access to a PPP server, you may want to try the freely
available MacPPP driver from Merit and University of Michigan. It is
available on most Mac archives, e.g. on ftp.tidbits.com in
/pub/tidbits/tisk/tcp. Rather complete documentation available from
the same sources. As with InterSLIP, it is crucial to get the
handshaking settings straight.

Instead of a script, MacPPP uses a set of edit fields in which you
enter the strings to wait for, and responses to send in order to
negotiate connection parameters. In the simplest scenario you would
simply tell MacPPP to wait for your server's prompt, and then send a
command requesting PPP mode. It is easy to make a mistake here,
forget to end the response with a carriage return, etc.

To see what your server sends during connection attempts, and to
experiment with the responses it may expect, you can simply dial into
it using a plain-vanilla terminal emulation package, e.g. ZTerm, and
jot down what happens on the screen.


Appendix D. MacTCP error codes

Please note: the information in this section is in no way blessed or
authorized by Apple Computer, Inc. It is simply a summary of
information contained in publicly available header files related to
MacTCP (those are Copyright: (C) 1984-1994 by Apple Computer, Inc.)
The list is not necessarily accurate nor up to date.

-23000    bad network configuration
-23001    bad IP configuration error
-23002    missing IP or LAP configuration error
-23003    error in MacTCP load
-23004    error in getting address
-23005    connection is closing
-23006    invalid length (of what??)
-23007    request conflicts with existing connection
-23008    connection does not exist
-23009    insufficient resources to perform request
-23010    invalid stream pointer
-23011    stream already open
-23012    connectionTerminated
-23013    invalidBufPtr
-23014    invalidRDS
-23014    invalidWDS
-23015    openFailed
-23016    commandTimeout
-23017    duplicateSocket

-23032    Packet too large to send w/o fragmenting
-23033    destination not responding
-23035    ICMP echo timed-out
-23036    no memory to send fragmented pkt
-23037    can't route packet off-net

-23041    nameSyntaxErr
-23042    cacheFault *
-23043    noResultProc
-23044    noNameServer
-23045    authNameErr
-23046    noAnsErr
-23047    dnrErr
-23048    outOfMemory